クラウドアーカイブの革命児！AWS Storage Gateway仮想テープライブラリを試してみた
ども、大瀧です。昨日、AWS Storage Gatewayの新機能、仮想テープライブラリがリリースされました。 Storage GatewayはAWSのサービスの中でも地味な方だと思いますが、個人的には今回の新機能はクラウドアーカイブの革命児と呼ぶにふさわしい画期的なものだと思っています。根拠は以下です。
- 従来のバックアップ製品と親和性が高い
- 普通のiSCSIテープデバイスとして扱えるので、従来のバックアップ製品+OS付属のiSCSIイニシエータで既存バックアップソフトのバックアップ先を変更するだけで、 AWSへのデータバックアップが可能になります。
- Glacierと連携する
- アーカイブ先としてS3に加えてAmazon Glacierを利用することによるコスト圧縮を実現できます。概算で、1TBのバックアップが月額1,200円 *1で済みます。Glacierを使うなら、Storage Gateway!と言われるようになるかもしれません。
- Storage Gateway : AMIバージョン1.03
- バックアップクライアント : EC2 Amazon Linux 2013.09
- テープ : 音楽カセットテープ(もはや死語になりつつありますが)と同様の、磁気テープをケースに格納したコンピュータデータ用のテープを指します。LTOやDDSなどいくつかの規格があります。
- テープドライブ : テープからデータを読み込み、書き込みするためのハードウェア。サーバーマシンとSCSIやUSBなどで接続します。制御するためには機器によって汎用あるいは専用のドライバが必要です。
- テープチェンジャ : かつてのCDチェンジャと同様、テープをテープドライブに自動で着脱するためのハードウェアです。通常は高価なデープドライブとセットになっていることが多く、定期的なバックアップや複数テープに渡る大容量バックアップなどで利用します。
- 東京リージョンの場合、データ転送料金を含まない ↩
概念図を以下に示します。
Storage Gateway on EC2の構成でAWS内で構築することも可能なので、検証してみました。
検証環境
この後の操作は、Storage GatewayインスタンスとバックアップクライアントのEC2での操作が交互に進んでいきますが、GUIの画面操作はStorage Gatewayインスタンス、CUIの端末操作はバックアップクライアントのEC2で区別いただけるとわかりやすいです。
[Storage Gateway]インスタンスの構成
まずは、Storage Gateway on EC2のインスタンスを作成します。この手順は、従来のStorage Gatewayと特に変わりません。Storage GatewayのAMIからEC2インスタンスを起動し、Public IPを控えます。具体的な手順は、望月さん執筆の以下のブログエントリーを参照ください。
[Storage Gateway]仮想テープライブラリの構成
Storage Gatewayの管理画面左側メニューの[Deploy a new Gateway on Amazon EC2]をクリックし、Storage Gatewayインスタンスを登録します。[Select Gateway Type]で「Gateway-Virtual Tape Library」を選択するのがポイントです。先ほど控えたインスタンスのPublic IPを入力し、[Proceed to Activation]をクリックします。
続いて、仮想テープライブラリの構成を入力します。[AWS Region]、[Gateway Time Zone]を選択し、[Gateway Name]は任意の名称を入力します。[Medium Changer Type]および[Tape Device Type]が気になるところですが、現状は「STK-L700」および「IBM-ULT3580-TDS」のみ選択できるため、実質決めうちです。[Activate My Storage Gateway]をクリックし、しばらく待ちます。
続いて構成ウィザードが表示され、キャッシュ、バッファディスクとSNSアラームを設定します。この辺りは従来と特に変わらないため、省略します。あらかじめEBSボリュームを作成し、Storage GatewayインスタンスにAttachしておきます。
ウィザードを進めると、仮想テープの作成画面が表示されます。ここで、テープ装置をよく知らない方のために、用語を整理しておきます。
[Number of Tapes]で、仮想テープライブラリで扱う仮想テープの本数、[Capacity]で仮想テープ1本あたりの容量、[Barcode Prefix]で仮想テープラベルの接頭辞を指定します。仮想テープは最大で10本まで、容量は100GB、200GB、400GB、800GB、1.5TB、2.5TBの6通りから選択します。キャッシュゲートウェイと同様に、テープ容量はインスタンスにひもづくキャッシュボリュームよりも大きいサイズでも選択できますが、運用時にはキャッシュボリュームの空き容量に注意する必要があります。今回は5本で容量1.5TBの仮想テープを作成してみます。[Create Tapes]をクリックします。
仮想テープライブラリ作成の完了画面では、作成された仮想テープドライブ(仮想テープの本数に関わらず固定で10個)と、仮想テープのメディアチェンジャ(仮想テープを仮想テープドライブに装着/取り外しするデバイス)のiSCSI名が表示されます。確認し、[Close]をクリックします。
Storage Gatewayの管理画面に、作成した仮想テープの一覧が表示されます。5本の仮想テープが、容量1.5TBで作成されたことが確認できます。
[VTL Devices]タブをクリックすると、仮想テープドライブおよび仮想メディアチェンジャ一覧が確認できます。
Storage Gatewayの準備はこれでOKです。
[EC2]iSCSIの構成
それでは、Amazon LinuxのEC2インスタンスから、Storage Gatewayインスタンスの仮想テープドライブにアクセスしてみます。まずは、Storage GatewayインスタンスとのiSCSI接続を確立するために、iSCSIイニシエータのインストールおよび構成を行います。望月さんのブログエントリーの通り、iSCSIイニシエータをiscsi-initiator-utilsパッケージでインストールし、iscsiadmコマンドでiSCSIイニシエータを構成します。以下のコマンドラインにある172.31.XX.XXは、Storage GatewayインスタンスのPrivate IPです。
$ sudo iscsiadm --mode discovery --type sendtargets --portal 172.31.XX.XX:3260 iscsid を起動中: [ OK ] 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-01 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-02 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-03 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-04 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-10 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-05 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-06 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-07 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-08 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-09 172.31.XX.XX:3260,1 iqn.1997-05.com.amazon:sgw-XXXXXXXX-mediachanger $
仮想テープドライブおよび仮想メディアチェンジャのiqn名が確認できます。続いて、1つ目のテープドライブとメディアチェンジャに接続します。
$ sudo iscsiadm --mode node --targetname iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-01 --login ogging in to [iface: default, target: iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-01, portal: 172.31.XX.XX,3260] (multiple) Login to [iface: default, target: iqn.1997-05.com.amazon:sgw-XXXXXXXX-tapedrive-01, portal: 172.31.XX.XX,3260] successful. $ sudo iscsiadm --mode node --targetname iqn.1997-05.com.amazon:sgw-XXXXXXXX-mediachanger --login Logging in to [iface: default, target: iqn.1997-05.com.amazon:sgw-XXXXXXXX-mediachanger, portal: 172.31.XX.XX,3260] (multiple) Login to [iface: default, target: iqn.1997-05.com.amazon:sgw-XXXXXXXX-mediachanger, portal: 172.31.XX.XX,3260] successful. $
接続できました。この時点でドライブおよびチェンジャに対応するデバイスファイルが、udevによって作成されます。/dev/sg?がテープドライブおよびチェンジャのデバイスファイル、/dev/st?がテープドライブのデバイスファイルです。
$ ls /dev/s{t,g}?
/dev/sg0 /dev/sg1 /dev/st0
$
今回のケースでは、/dev/sg0が仮想メディアチェンジャ、/dev/st0が仮想テープドライブのデバイスファイルに対応します。
[EC2]仮想テープの構成
デバイスファイルが準備できたので、ここからは通常のテープドライブおよびメディアチェンジャの操作と同様です。Amazon Linuxには、ドライブおよびチェンジャの操作を行うmt-stパッケージおよびmtxパッケージが用意されていないため、CentOSのSRPMからRPMパッケージをビルドし、インストールします。
$ sudo yum groupinstall -y "Development Tools" $ wget http://vault.centos.org/6.4/os/Source/SPackages/mt-st-1.1-5.el6.src.rpm $ sudo rpmbuild --rebuild mt-st-1.1-5.el6.src.rpm $ sudo rpm -ivh /usr/src/rpm/RPMS/x86_64/mt-st-1.1-5.amzn1.x86_64.rpm $ wget http://vault.centos.org/6.4/os/Source/SPackages/mtx-1.3.12-5.el6.src.rpm $ sudo rpmbuild --rebuild mtx-1.3.12-5.el6.src.rpm $ sudo rpm -ivh /usr/src/rpm/RPMS/x86_64/mtx-1.3.12-5.amzn1.x86_64.rpm
mtxコマンドをメディアチェンジャのデバイスファイルに対して実行し、仮想テープライブラリの現在の状態を確認します。現在、いずれのテープドライブにも仮想テープは装着されておらず、未装着のテープが5本あることが確認できます。
$ sudo mtx -f /dev/sg0 status | less
Data Transfer Element 0:Empty
Data Transfer Element 1:Empty
Data Transfer Element 2:Empty
Data Transfer Element 3:Empty
Data Transfer Element 4:Empty
Data Transfer Element 5:Empty
Data Transfer Element 6:Empty
Data Transfer Element 7:Empty
Data Transfer Element 8:Empty
Data Transfer Element 9:Empty
(略)
Storage Element 1600 IMPORT/EXPORT:Full :VolumeTag=AMZNA54000
Storage Element 1601 IMPORT/EXPORT:Full :VolumeTag=AMZNA44001
Storage Element 1602 IMPORT/EXPORT:Full :VolumeTag=AMZNA74002
Storage Element 1603 IMPORT/EXPORT:Full :VolumeTag=AMZNA64003
Storage Element 1604 IMPORT/EXPORT:Full :VolumeTag=AMZNA14004
(略)
$
仮想テープドライブに仮想テープを装着します。
$ sudo mtx -f /dev/sg0 load 1600 Loading media from Storage Element 1600 into drive 0...done $ sudo mtx -f /dev/sg0 status | less Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = AMZNA54000 (略) $
これで、/dev/st0に仮想テープ AMZNA54000が装着されました。バックアップの準備完了です。
[EC2]バックアップの実行
Linuxでテープバックアップを行うコマンドは複数ありますが、ファイル単位ではtarコマンド、ファイルシステム単位ではdumpコマンドを利用するのが一般的でしょう。今回はサンプルとして、CentOSのインストールDVDのISOイメージファイル2つを、tarコマンドで仮想テープに書き込みます。事前にmtコマンドでテープ装置の状態を確認し、tarコマンドでバックアップを実行します。
$ sudo mt -f /dev/st0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 0 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN $ ls CentOS-6.4-x86_64-bin-DVD1.iso CentOS-6.4-x86_64-bin-DVD2.iso $ sudo tar cvf /dev/st0 CentOS-6.4-x86_64-bin-DVD* CentOS-6.4-x86_64-bin-DVD1.iso (数分かかります) CentOS-6.4-x86_64-bin-DVD2.iso (数分かかります) $
仮想テープにバックアップが作成されました。このバックアップデータはStorage Gatewayインスタンスにキャッシュされ、非同期でS3に退避されます。
[EC2]仮想テープシェルフ(Glacier連携)への格納
S3との同期が完了したあとも、引き続き/dev/st0ファイル経由でバックアップ/リストアが実行できますが、Glacierにデータを退避させる場合は、仮想テープをテープドライブから取り外します(unload)。
$ sudo mtx -f /dev/sg0 unload 1600 0 Unloading drive 0 into Storage Element 1600...done
これでOKです。仮想テープの一覧画面では、仮想テープの状態が[AVAILABLE]から[IN TRANSIT TO VTS](仮想テープシェルフ(Glacier)へ退避中)に変わります。
仮想テープシェルフ(Glacier)への移動が完了すると、仮想テープ一覧のリストからは削除されます。
画面左のメニューから[Virtual Tape Shelf(VTS)]を選択すると、退避した仮想テープが確認できます。これで、仮想テープのデータが現在Glacierに保管されていることがわかります。
[Storage Gateway]仮想テープシェルフからの復帰
元の仮想テープライブラリに戻す場合は、[Retrieve Tape]ボタンをクリックします。Storage Gatewayインスタンスを選択し、[Proceed]をクリックします。
[Status]列が「RETRIEVING」になったら、仮想テープライブラリへの復帰中です。通常のGlacier→S3への復帰と同様、時間がかかります。気長に待ちましょう。
まとめ
今回は、仮想テープライブラリのStorage Gatewayによるバックアップを試してみました。一般のLinuxコマンドを用いましたが、他のバックアップソフトでのバックアップにも応用できる部分が多いのではないかと思います。大昔に勉強したテープ操作のコマンドを、まさかまた使う日が来るとは思っていませんでしたが、ITの知識は思わぬところで役に立つものですね。
皆さんも、オンプレミス/AWS環境のバックアップをStorage Gatewayで効率よく行いましょう！
